Method, network access element and mobile node for service advertising and user authorization in a telecommunication system

ABSTRACT

A network access sequence for a mobile node (MN) in one or more foreign domains (FD). A foreign domain sends (A 1 ) service advertisement messages (M 1 ), each of which comprises an identifier ( 41 ) of the message, network address information ( 43 ) and a detailed service offering ( 42 ). The mobile node stores (A 2 ) the detailed service offerings and selects one of them. Then it sends a service request message (M 2 ) to the foreign domain which sent the selected service offering ( 62 ). The service request indicates ( 55 ) the selected service offering ( 62 ) and the mobile node&#39;s credentials ( 54 ). The foreign domain conveys the credentials to the mobile node&#39;s home domain (HD) for authentication and authorization and checks (A 4 ) if the selected service offering ( 62 ) can be supported. Next the foreign domain (FD) allocates communication resources for supporting the selected service offering and indicates (M 9 ) to the mobile node the availability of the requested service.

BACKGROUND OF THE INVENTION

[0001] The invention relates to methods and equipment for serviceadvertising and user authorization in a telecommunication system.

[0002] Two trends in telecommunications act as a driving force for theinvention. One of the trends is the fact that distinctions betweendifferent communication technologies and terminal equipment will beincreasingly blurred, and a single multi-mode terminal will be used toaccess a wide variety of different services, such as e-mail, websurfing, radio and TV programs, etc. Multimode terminals have severalalternative access techniques, such as any combination of cellular radio(GSM, GPRS, UMTS, etc.), DAB, DVB, WLAN, etc. The other trend is thatbackbone networks are increasingly based on Internet Protocol (IP).

[0003] In a GSM environment, operator (network) selection is simple: asubscriber of a given network cannot normally select another operator inhis/her home country. When roaming abroad, most mobile phones select thestrongest carrier unless the user manually overrides the phone'sautomatic selection.

[0004] A first problem with multi-mode terminals is that a manualnetwork selection is too cumbersome, and an automatic selection based onsignal strength is not sufficient. Thus there is need for more advancednetwork selection. Such an advanced network selection in turn causes asecond problem, namely the fact that a terminal (or its user) should beauthenticated in several networks before the terminal can select anetwork. The multiple authentication in turn has a third problem whichhas not existed in earlier systems, namely a complete lack of trustbetween a network operator and roaming user. In conventional mobilenetworks, such as GSM, the network infrastructure is so expensive andextensive that a roaming user, seeing an operator's name on the displayof the terminal, can automatically trust that the operator is what itclaims to be. In other words, it is infeasible to set up a GSM networkfor fraudulent purposes, such as eavesdropping. In WLAN environments,for example, this assumption may not be valid. For example, it ispossible for an eavesdropper to set up a WLAN system in places whereimportant information can be obtained. If the eavesdropper's systemoffers WLAN services that seem more attractive than those of itscompetitors, a terminal may select an untrustworthy network, and dataprivacy will be lost. Thus a novel problem is that not only must anetwork operator authenticate a roaming user but the user must also beable to establish trust with the network operator.

DISCLOSURE OF THE INVENTION

[0005] An object of the invention is to provide a mechanism for solvingthe first and second problems stated above. In other words, an object ofthe invention is to provide a network access sequence in which a mobilenode in a foreign domain can register to use the services of an optimalservice provider.

[0006] This object is achieved with a method and equipment which arecharacterized by what is disclosed in the attached independent claims.Preferred embodiments of the invention are disclosed in the attacheddependent claims.

[0007] A network access sequence according to the invention forproviding services to a mobile node in one or more foreign domains canbe implemented as follows. The foreign domains send serviceadvertisement messages, each service advertisement message comprising 1)an identifier of the service advertisement message in question; 2)network address/identity information relating to the foreign domain inquestion; and 3) a detailed service offering. The mobile node receivesand stores (at least temporarily) the detailed service offerings andselects a detailed service offering. The mobile node sends a servicerequest message to the foreign domain which sent the selected serviceoffering. The service request message indicates the selected serviceoffering and the credentials of the mobile node. The foreign domainconveys the credentials of the mobile node to the mobile node's homedomain for authentication and authorization. The foreign domain checksif the selected service offering can be supported on the basis ofavailable communication resources, and if it can be supported, theforeign domain allocates communication resources for supporting theselected service offering and indicates to the mobile node theavailability of the selected and requested service.

[0008] According to a preferred embodiment of the invention, the foreigndomain certifies each service advertisement message with a digitalcertificate and the mobile node verifies the digital certificate byopening it with the foreign domain's public key. In this way, the thirdproblem above is solved and a two-way trust relationship is dynamicallyestablished between the mobile node and the foreign domain.

[0009] According to another preferred embodiment of the invention, theforeign domain performs the resource-checking step after it has conveyedthe credentials of the mobile node to the mobile node's home domain forauthentication and authorization. In this way the resource-checking andthe authentication/authorization steps can be performed in parallel,which saves time.

BRIEF DESCRIPTION OF THE DRAWINGS

[0010] The invention will be described in more detail by means ofpreferred embodiments with reference to the appended drawings in which:

[0011]FIG. 1 illustrates a trust model according to the invention;

[0012]FIG. 2 illustrates how the trust model can be mapped to concretenetwork elements;

[0013]FIG. 3 is a signalling diagram illustrating a mobile node'sregistration procedure according to a preferred embodiment of theinvention;

[0014]FIG. 4 illustrates a service advertisement message;

[0015]FIG. 5 illustrates a service request message; and

[0016]FIG. 6 is a signalling diagram illustrating a process in which amobile node selects a service offering among the various serviceofferings sent by different mobile networks.

DETAILED DESCRIPTION OF THE INVENTION

[0017] Preferred embodiments of the invention will be described usingthe following terminology. Since the term “network” is somewhat vague,the term “domain” will be used instead. A domain is one or more portionsof a telecommunication system under a common administration. Asubscriber's home domain (network) is the domain with the operator ofwhich the subscriber has a subscription. Other domains are foreigndomains. The term “network” will be used in connection withwell-established terms like “network access” , “network address” or“network element”. In Mobile IP (Internet Protocol), the terms homeagent-and foreign agent are frequently used. The term “attendant”, asused herein, is a close relative of a foreign agent known from theMobile IP protocol (MIP). To be more precise, “foreign agent” is a termused in connection with the Mobile IP protocol, whereas “attendant” iscommonly used in an AAA environment. An AAA attendant may constitute apart of a MIP foreign agent.

[0018]FIG. 1 illustrates a trust model according to the invention. Amobile node MN, whose home domain is HD, is going to register in aforeign domain FD. Each domain has an AM element or server. ‘AAA’ standsfor authentication, authorization and accounting. The AM of the mobilenode's home domain is called AAAH, and the one in the foreign domain iscalled AAAL. (In some documents, it is called AAAF, wherein ‘F’ meansforeign, but AAAL appears to be more common.) That is, each AAA elementacts as an AAAH to mobile nodes of its own domain and as an AAL toroaming mobile nodes. There is also an attendant ATT for assisting themobile node's registration process. A possible location of the attendantis within a MIP (Mobile IP) foreign agent. The intervening networkelements, such as radio stations and the like, have been omitted forclarity.

[0019] At the beginning of the registration process, the operator of theforeign domain FD cannot trust the mobile node MN, and the MN usercannot automatically trust the FD operator. But there is static(permanent) trust between the mobile node and its AAAH. Likewise, theforeign domain's AAAL has a static trust relationship to the attendantin the same FD. Between the domains HD and FD, a trust relationship canbe negotiated, for example by exchanging digital certificates. In otherwords, there is a negotiable trust relationship between the HD and FD. Aproblem is that the mobile node cannot directly access its home domain(which it trusts) but only via the foreign domain's attendant, and thereis a two-way lack of trust between the mobile node and the attendant.According to the invention, a dynamic trust relationship is establishedbetween the mobile node and the attendant, as will be shown in in moredetail in connection with FIG. 3. A dynamic trust relationship is ashort-term trust relationship. It is typically negotiated via one ormore third parties for the duration of one session.

[0020]FIG. 2 illustrates how the trust model can be mapped to concretenetwork elements. In FIG. 2, there is a wireless local area network WLANcomprising three base stations BS. Each base station has an integratedattendant. There is an AAAL server serving the WLAN network and afilter/router F/R for communicating with external networks, one of whichis the mobile node's home domain. The attendant extracts identificationand authorization data sent by the mobile node and forwards them to theAAAL for verification. It is also responsible for configuring thefilter/router F/R so that only authorized clients can access thenetwork.

[0021]FIG. 3 is a signalling diagram illustrating a network accesssequence according to a preferred embodiment of the invention. Theprocedure is based on a protocol referred to as Diameter, and it isspecified in references [DIA base] and [DIA mobile]. The references arelisted at the end of this description. The procedure shown in FIG. 3comprises 10 actions and 9 messages. The actions are labelled A1 throughA10, and the messages are labelled M1 through M9. This embodimentproposes changes to actions A1, A2, A4 and A10 and to messages M1, M2,M3, M8 and M9. In FIG. 3 these actions and messages are shown in a boldtypeface. The remaining actions and messages can be as specified in theDiameter references.

[0022] In action A1, a local AAA server AAL maintains a database (ortable) of the services offered by it. The services are accompanied withother relevant parameters, for example cost, availability, etc. The AAALis triggered to select periodically one or more services to be offeredto mobile clients. After that, the AAAL prepares a service offering tobe delivered for a mobile node or a group of mobile nodes.

[0023] Message M1 comprises the actual service offering by the AAAL. Theformat and the delivery technique of the service offering are notessential for the invention. Possible delivery techniques include arouter advertisement, an on-request reply and broadcasting over somecontrol channel. Only the information contained in the service offeringis important. A service offering should contain at least items 1 through4 of the following list, and optionally items 5 and/or 6:

[0024] 1. SO_ID (=service offering identifier): A unique identifier ofthe service offering. The identifier serves to distinguish serviceofferings having the same origin.

[0025] 2. SO-PLD (service offering—payload): The payload or the actualservice being offered. The format and contents are not essential for theinvention. An example of a service offering payload will be described inconnection with FIGS. 4 and 6.

[0026] 3. FD-NAI (Foreign Domain—Network Access Identifier): Identifiesthe sender of the service offering in the foreign domain, preferably inthe form of a Network Access Identifier (NAI), see [DIA Base]. Acombination of a SO_ID and a FD-NAI is globally unique.

[0027] 4. ATT-ADDR (Attendant Address): Network or link level accessinformation on how to contact an attendant that can accept a request forthis service offering. This may be an IP address, MAC address or even avalid socket address for an application.

[0028] 5. VALID: An optional validity time indicating how long theservice offering remains valid.

[0029] 6. SIG-FD: An optional digital signature signed by the sendingAAAL. Any signature algorithm can be used. For example, the signaturecan be calculated over the remaining items 1 through 5 of the serviceoffering message.

[0030]FIG. 4A illustrates how the above items can be sent in a serviceadvertisement message. Field 41 is the service offering identifier SO_IDwhich will be used later to identify the service offering selected bythe mobile node. Field 42 is the service offering payload SO_PLD whichspecifies the details of the actual offering, such as the tariff,bandwidth (speed), maximum delay, maximum error rate, etc. Fields 44 and45 constitute network access information 43 which is basically thecontents of a prior art service/router advertisement message. Field 46is optional and indicates the validity time/period of the serviceoffering. Field 47 is also optional. It is a digital signature computedover the remaining fields of message M1 and signed with the private keyof the foreign domain FD. By verifying this signature with the publickey of the foreign domain, the mobile node may confirm the identity ofthe sender of message M1 (in this case, the AAAL).

[0031] It is interesting to note that prior art service/routeradvertisement messages are routinely called “advertisement messages”.There is even a well-established session announcement protocol (SAP)that comprises such an advertisement message. But in the prior art, theservice advertisement messages are used only to proclaim the existenceof a network elements (a server or router). Prior art serviceadvertisement messages have not been used to advertise services in thetraditional meaning of the word “advertise”. At best, the prior artservice advertisement messages perform brand advertising (“I am here”)but not detailed advertising (“I offer this QoS at that price”). Inother words, a mobile node receiving prior art service advertisementmessages from multiple foreign domains has no way of knowing whichdomain offers the best price/service ratio, such as the best price at agiven quality of service (QoS) which is required for a givenapplication. Alternatively, the mobile node may need to know whichforeign domain offers the best QoS at a given price. Depending on theapplication type, the QoS may comprise factors like nominal bandwidth(data rate), minimum/maximum guaranteed bandwidth, packet delay anddelay variability, guaranteed or worst-case error rate, packet lossprobability, priority, etc. According to the invention, an advertisementmessage comprises not only an advertisement but an offer which isdetailed enough to enable a meaningful comparison between serviceproviders. A meaningful comparison requires not only knowledge of aservice provider's existence (which is offered by the prior artservice/router advertisement messages) but also price/tariff informationand the quality of service to be delivered at the advertised price.

[0032] A traditional business model is that a client reacts to anadvertisement by requesting a detailed offer, and the service providerresponds to the request for offer by providing a detailed offer. Theinvention breaks this business model by sending a (sufficiently)detailed offer with the advertisement message, that is without anexplicit request from the client.

[0033]FIG. 5 illustrates an example of a service request message M2.Field 51 is a mobile IP registration request, which is known from priorart. Fields 53 through 55 constitute the actual service request 52 whichis related to requesting the service according to the service offeringselected by the mobile node. Field 53 is a Mobile IP Network AccessIdentifier Extension for IPv4 (see RFC 2794). Field 54 is the mobilenode's credentials, such as Mobile IP Challenge/Response Extensions (seeRFC 3012). Field 55 identifies the service offering selected by themobile node (or its user).

[0034] Reference is again made to FIG. 3. Action 1 and message 1 can berepeated any number of times. FIG. 3 also shows service offerings fromtwo additional AAAL servers, namely AAAL′ and AAAL″.

[0035] In action A2, a mobile node receives one or more serviceofferings from one or more sources in foreign domains. Based on userneeds, the mobile node selects one service offering. Details of theselection mechanism are beyond the scope of this invention. For example,the selection can be based on factors such as the offered price,bandwidth, maximum delay, error rate, etc.

[0036] If the service offering comprises a digital signature, the mobilenode can use the signature to verify the service offering beforetrusting its sender and selecting the service offering. For example, themobile node may use a pre-defined key to check incoming serviceofferings with signatures. Alternatively, it can dynamically use someexternal public key infrastructure for obtaining the sender's publickey.

[0037] Message M2 comprises a service request (SR) from the mobile node.The mobile node constructs a service request on the basis of theinformation in the selected service offering. The MN then sends the SRto the attendant specified by the ATT-ADDR field of the serviceoffering. Message M2 must also contain the necessary information contentspecified in [DIA mobile]. One way to convey the SR to the attendant isto include a Mobile IP version 4 (MIPv4) mobile node registrationrequest in a new message type. MIPv4 will be the default case from nowon. A service request SR contains at least the following items:

[0038] 1. MN_NAI: The mobile node's Network Access Identifier. Itidentifies the mobile node (or its user) and its home domain, and homeauthority (AAAH).

[0039] 2. AAA_CRED: The AAA credentials (for example a signature of achallenge or a whole SR). AAA_CRED is the token which the AAAH uses toauthenticate the mobile node or its user.

[0040] 3. SO_ID: The identifier of the selected service offering (seeMessage M1).

[0041] The MN_NAI and AAA_CRED are required in the procedure specifiedin [DIA mobile]. By incorporating or attaching the SO_ID to the servicerequest SR, the AAAL may begin resource allocation while the mobilenode's home domain completes the authentication and authorizationprocess. Also, there is no need to authorize the MN in respect ofservices it is not requesting.

[0042] In action A3, the attendant ATT processes the SR transparently.The ATT extracts the information from message M2 as described in [DIAmobile] to construct a DIAMETER AMR (also described in [DIA mobile]).The attendant also includes the SR in the DIAMETER AMR as a new AVP(Attribute-Value Pair). According to the invention, the DIAMETER AMRalso carries the mobile node's service request.

[0043] In message M3, the attendant ATT sends the newly-constructedDIAMETER AMR with the included SR to the local authority of the foreigndomain. See [DIA mobile] for details.

[0044] In action A4, the AAAL checks the validity of the serviceoffering and checks if the requested service can be supported. For userauthentication and authorization, the AAAL relies on the home authority(AAAH) of the user like in [DIA mobile]. The checking step is relevantto the invention.

[0045] Messages M4 through M7 and actions A5 through A7 relate toauthenticating the mobile node in its home domain. They are normalDiameter messages and actions, see [DIA mobile] for details.

[0046] Action A4 can be performed in any one of three alternative placesin the chain of events shown in FIG. 3, namely before message M4,sometime between messages M4 and M7 or after message M7. Preferably, theAAAL performs action A4 after sending message M4. This way, the AAAL canperform the checks in action A4 while the home domain authenticates andauthorizes the mobile node.

[0047] In action A8, the AAAL receives an AMA (AA-Mobile-Node-Answer)from the AAAH. The result of the authentication may be success orfailure. In case the authentication is successful, message M7 containsan MIPv4 registration reply (or MIPv6 binding reply). The AAALconstructs its own reply message M8 which is a normal DIAMETER AMAappended with the information content of service indication (SI). Addingthe SI to the registration reply is an essential feature of theinvention. The service indication contains at least items 1 and 2 of thefollowing list, and optionally items 3 and/or 4:

[0048] 1. SI_STATUS: The status, or answer, to the service request. Itindicates success (0) or failure (any other value).

[0049] 2. FD-AUTH: A foreign domain authenticator. An example: theentire SI message signed with the MN-FD_key. A mobile node can verifythis after recovering the MN-FD_key from the SI message.

[0050] 3. SI_INFO: additional information (optional). For example, incase of success, this field may contain link-level access information,an IP address and other configuration information from the AAAL. In caseof failure, this field may contain a more detailed description of thereason of the failure.

[0051] 4. MN-FD_key: An optional session key to be used between themobile node and the foreign domain. It should always be originated fromthe AAAH and encrypted by the MN-AAAH key.

[0052] If the authentication is successful, the AAAL sends message M8 tothe attendant. M8 comprises a DIAMETER AMA with an included SI.

[0053] In action A9, the attendant obtains the session keys to be usedfor communicating with the mobile node (and the mobile node's homeagent, in case MIPv4 is used). According to the service indication, theattendant grants resources to the mobile node. A simple implementationof resource granting is that the attendant merely allows the mobilenode's traffic to pass the attendant from this moment on.

[0054] Message M9 delivers the service indication to the mobile node.

[0055] Action A10 completes the chain of events shown in FIG. 3. Themobile node verifies the received service indication (if the optionalsignature is used) and the binding acknowledgement BA, and begins to usethe offered service.

[0056]FIG. 6 is a signalling diagram illustrating a process in which amobile node selects a service offering among the various serviceofferings sent by different mobile operators. Actions A1, A2, etc., andmessages M1 through M9 shown in FIG. 6 are basically similar to thecorresponding elements in FIG. 3, the difference being that in FIG. 6the emphasis is on the service offerings and service requests.

[0057] In the example shown in FIG. 6, action A1 comprises sendingseveral service offerings SO#1 through SO#15 from two local AAA serversAAAL and AAAL′. The domain (network) addresses of the AAAL servers arexyz.com and foo.net, respectively. In FIG. 6, the detailed serviceoffering 42 has been divided into two fields 61 a and 61 b. Field 61 aindicates a price or tariff and field 61 b indicates the quality ofservice at the offered price or tariff. For example, a first serviceoffering has an identifier SO#1, and it indicates a tariff of 15

(currency units) per megabyte and a maximum data rate of 1 megabit persecond. As indicated by its field 46, the service offering is valid forone hour. The remaining service offerings are constructed similarly, butidentifiers SO#6 and SO#12 relate to offerings with a minute tariffinstead of a megabyte tariff. All offerings SO#1 through SO#15 arecollectively referred to as message M1 and the act of sending them iscollectively referred to as action A1.

[0058] In order to maintain the clarity of, FIG. 6, the quality ofservice field 61 b comprises only one component, namely a nominalbandwidth. As stated earlier, the QoS may also comprise othercomponents, such as a guaranteed bandwidth, packet delay and delayvariability, guaranteed or worst-case error rate, packet lossprobability, priority, etc. (In all radio traffic, however, “guaranteed”should be interpreted as “best-effort”.) Although all the exampleservice offerings in FIG. 6 SO#1 through SO#15 relate to simple bearer(connectivity) services, the services to be offered can comprise moreadvanced services, such as a user's ability to create multicastsessions, etc.

[0059] In action A2, the mobile node MN receives and collects (at leasttemporarily) the service offerings having the identifiers SO#1 throughSO#15 sent by different mobile operators. At this stage, the mobile nodecan either present the service offerings to its user and receive theuser's selection, or it can perform the selection automatically, on thebasis of some pre-stored criteria, such as the lowest tariff among theservices meeting some minimum requirements (bandwidth, error rate,delay, delay variance, etc.) In this example, the mobile node or itsuser selects service offering 62 from xyz.com. Next the mobile node MNsends message M2 to the attendant ATT. Message M2 comprises a servicerequest SR which in turn comprises the FD_NAI (xyz.com) of the AAAL, theidentifier of the selected service offering (SO#6), the MN user'snetwork address in its home domain (john.doe@home.org) and the mobilenode's (or its user's) AAA credentials which is a digital certificate.The attendant conveys the contents of message M2 to the AAAL in messageM3.

[0060] At this stage, the AAAL does not yet trust the mobile node MN.Therefore the AAAL sends the mobile node's credentials to the MN's homeAAA server AAAH for authentication and authorization.

[0061] The fact that the mobile node MN receives and collects serviceofferings sent by different mobile operators has several alternativeimplementations. For example, the mobile node may collect serviceofferings until it appears to have all the available information; inother words, the MN receives repeated service offerings. After that, theMN or its user may select an optimal service offering. Alternatively,the mobile node may have a set of criteria for each application, such asa minimum bandwidth/maximum price, and as soon as a service offeringfulfils the criteria, it is automatically selected. The actual selectionprocess is not relevant to the invention. Also, the mobile node mayselect more than one service offering, such as one for voice calls andanother for file downloads.

[0062] The above description is not tied to any specific protocolversions. Three different implementations with different protocols willbe described next. The differences are limited to the over-the-airmessages M1, M2 and M9. The three different protocols are Mobile IPversion 4 (MIPv4), Mobile IP version 6 (MIPv6) and AAA version 6(AAAv6).

[0063] In a MIPv4 implementation, message M1 can be transported in anICMP (Internet Control Message Protocol) Router Advertisement. M1 mayappear with a Mobility Agent Advertisement Extension [RFC 2002, 2.1.1].The service offering identifier SO_ID and the service offering payloadSO_PLD (fields 41 and 42 in FIG. 4) can be implemented as new extensionsto ICMP Router Advertisements. The Foreign Domain Network AccessIdentifier FD_NAI (field 44) can be implemented as a generalized NAIExtension. For an implementation of a NAI extension, reference is madeto [AA]. The attendant address ATT_ADDR, validity period VALID and theforeign domain signature FD_SIG (fields 45, 46 and 47) can beimplemented as new extensions to ICMP Router Advertisements.

[0064] Message M2 can be transported in a MIPv4 registration request.The actual registration request (field 51 in FIG. 5) can be a plainMIPv4 registration request header, see [RFC 2002]. The MN's NetworkAccess ID MN_NAI (field 53) can be as disclosed in [RFC 2794]. The MN'scredentials AM_CRED (field 54) can be as disclosed in [RFC 3012]. Theservice offering identifier SO_ID (field 55) can be a new extension to[RFC 2002]. Finally, message M9 may be an MIPv4 registration replyappended with a new extension to support service indication (SI).

[0065] In an MIPv6 implementation, message M1 can be transported in anIPv6 Neighbour discovery message, see [RFC 2461]. M1 may appear with amodified Router Advertisement Message, see [MIPv6]. The service offeringidentifier SO_ID and the service offering payload SO_PLD (fields 41 and42 in FIG. 4) can be implemented as new extensions to ICMPv6 RouterAdvertisements. The Foreign Domain Network Access Identifier FD_NAI(field 44) can be implemented as a generalized NAI Extension. Theattendant address ATT_ADDR, validity period VALID and the foreign domainsignature FD_SIG (fields 45, 46 and 47) can be implemented as newextensions to ICMPv6 Router Advertisements.

[0066] Message M2 can be transported in a MIPv6 registration request.The actual registration request (field 51 in FIG. 5) can be a plainMIPv6 registration request header, see [MIPv6]. The MN's Network AccessID MN_NAI (field 53) can be carried as a client identifier option, see[AAA]. The MN's credentials AAA_CRED (field 54) can be carried as aSecurity Data option, see [AM]. The service offering identifier SO_ID(field 55) can be a new option. Message M2 thus requires a new option inaddition to a binding update (BU) option. Finally, message M9 may be anMIPv6 registration reply appended with a new extension to support SI.

[0067] The AAAv6 specifications do not list any specific ways oftransporting message M1, but it can be transported in one of at leastthree ways, namely 1) in a MIPv4 router advertisement (in an MIPv4implementation), 2) in a MIPv6 router advertisement option plus a newextension (MIPv4 implementation), or 3) as a new ICMPv6 message). All ofthe above fields 41, 42 and 44 through 47 can be implemented as newoptions to AAAv6. Message M2 can be transported in a MIPv6 registrationrequest. The actual registration request (field 51 in FIG. 5) can be aplain MIPv6 registration request header, see [RFC 2002]. The MN'sNetwork Access ID MN_NAI (field 53) can be carried as a clientidentifier option, see [AAA]. The MN's credentials AM_CRED (field 54)can be carried as a Security Data option, see [AAA]. The serviceoffering identifier SO_ID (field 55) can be a new option. Finally,message M9 may be an MIPv6 registration reply appended with a newextension to support SI.

[0068] In some cases, message M1 can be described in session descriptionprotocol (SDP) and carried to the end user via session announcementprotocol (SAP). In such cases, the service is most likely a multicastsession. If the SDP protocol is extended, it will be possible todescribe more abstract services.

[0069] Although the invention has been described in connection with somespecific embodiments, it is not limited to these examples but it can bevaried within the scope of the appended claims.

References

[0070] [AAA]: AAA for IPv6 Network Access, Internet draft by Charles E.Perkins et al. (“draft-perkins-aaav6-02.txt”)

[0071] [DIA base]: Diameter Base protocol, Internet draft by Pat R.Calhoun et al. (“draft-calhoun-diameter-17.txt”)

[0072] [DIA mobile]: Diameter Mobile-IP Extensions, Internet draft byPat R. Calhoun et al. (“draft-calhoun-diameter-mobileip-11.txt”)

[0073] [MIPv6]:www.ietf.org/internet-drafts/draft-ietf-mobileip-ipv6-13.txt

[0074] The above Internet drafts and RFC 2002, 2461, 2794 and 3012 canbe found at address http://search.ietf.org/internet-drafts

[0075] All references are incorporated herein by reference.

Acronyms (some are not Official)

[0076] AA: Authentication & Authorization

[0077] AAA: Authentication, Authorization and Accounting

[0078] AMH: an AM server in a mobile node's home domain

[0079] AAAL: a local AAA server, also called AAAF (F=foreign)

[0080] AMA/AMR: M Mobile node Answer/Request

[0081] AVP: Attribute-Value Pair

[0082] BA: Binding Acknowledgement

[0083] BU: Binding Update

[0084] FD: Foreign domain

[0085] HAR: Home-Agent-MIP-Request

[0086] HD: Home domain

[0087] ICMP: Internet Control Message Protocol

[0088] MIP: Mobile IP

[0089] MN: Mobile Node

[0090] MN-FD_key: a key used between a mobile node and a foreign domain

[0091] NAI: Network Access Identifier

[0092] SAP: Session Announcement Protocol

[0093] SI: Service Indication

[0094] SIG_FD: a packet digitally signed by the private key of a FD (anAAAL)

[0095] SO: Service Offering

[0096] SR: Service Request

1. A method for performing a network access sequence for a mobile node (MN) in one or more foreign domains (FD), characterized by the steps of: the one or more foreign domains (FD) sending (Al) service advertisement messages (M1), each service advertisement message comprising: an identifier (41) of the service advertisement message in question; network address/identity information (43) relating to the foreign domain in question; and a detailed service offering (42); the mobile node (MN) receiving and storing (A2) the detailed service offerings (42) and forming an indication (55) of a selected detailed service offering (62); the mobile node (MN) sending a service request message (M2) to the foreign domain (FD) which sent the selected service offering (62), the service request message (M2) comprising the indication (55) of the selected service offering (62) and the mobile node's credentials (54); the foreign domain (FD) conveying (M4-M7) the mobile node's credentials (54) to the mobile node's home domain (HD) for authentication and authorization; the foreign domain (FD) checking (A4) if the selected service offering (62) can be supported on the basis of available communication resources; if the selected service offering (62) can be supported, the foreign domain (FD) allocating communication resources for supporting the selected service offering and indicating to the mobile node the availability of a service according to the selected service offering.
 2. A method for performing a network access sequence for a mobile node (MN) in one or more foreign domains (FD), characterized by the steps of: the one or more foreign domains (FD) sending (Al) service advertisement messages (M1), each service advertisement message comprising: network address/identity information (43) relating to the foreign domain in question; and a detailed service offering (42); the mobile node (MN) receiving and storing (A2) the detailed service offerings (42) and forming an indication (55) of a selected detailed service offering (62), and calculating an identifier (41) of the service advertisement message in question; the mobile node (MN) sending a service request message (M2) to the foreign domain (FD) which sent the selected service offering (62), the service request message (M2) comprising the indication (55) of the selected service offering (62) and the mobile node's credentials (54); the foreign domain (FD) conveying (M4-M7) the mobile node's credentials (54) to the mobile node's home domain (HD) for authentication and authorization; the foreign domain (FD) checking (A4) if the selected service offering (62) can be supported on the basis of available communication resources; if the selected service offering (62) can be supported, the foreign domain (FD) allocating communication resources for supporting the selected service offering and indicating to the mobile node the availability of a service according to the selected service offering.
 3. A method for performing a network access sequence for a mobile node (MN) in one or more foreign domains (FD), characterized by the steps of: the one or more foreign domains (FD) sending (A1) service advertisement messages (M1), each service advertisement message comprising: an identifier (41) of the service advertisement message in question; network address/identity information (43) relating to the foreign domain in question; and the mobile node (MN) receiving and storing (A2) the identifier (41), extracting therefrom a detailed service offering (42); and forming an indication (55) of a selected detailed service offering (62); the mobile node (MN) sending a service request message (M2) to the foreign domain (FD) which sent the selected service offering (62), the service request message (M2) comprising the indication (55) of the selected service offering (62) and the mobile node's credentials (54); the foreign domain (FD) conveying (M4-M7) the mobile node's credentials (54) to the mobile node's home domain (HD) for authentication and authorization; the foreign domain (FD) checking (A4) if the selected service offering (62) can be supported on the basis of available communication resources; if the selected service offering (62) can be supported, the foreign domain (FD) allocating communication resources for supporting the selected service offering and indicating to the mobile node the availability of a service according to the selected service offering.
 4. A method according to claim 1, 2 or 3, characterized by the steps of: the foreign domain (FD) signing the service advertisement messages (M1) with a digital signature (47); and the mobile node (MN) verifying the digital signature (47); wherein a two-way trust relationship is dynamically established between the mobile node (MN) and the foreign domain (FD).
 5. A method according to any of the claims 1 to 4, characterized by the foreign domain (FD) performing the checking step (A4) after it has performed the conveying step (M4-M7).
 6. A method according to any one of claims 1 to 5, characterized by the mobile node (MN) automatically forming the indication (55) of the selected service offering (62) on the basis of pre-stored criteria.
 7. A method according to any one of claims 1 to 5, characterized by the mobile node (MN) forming the indication (55) of the selected service offering (62) by presenting the detailed service offerings to a user and by receiving the user's selection.
 8. A method according to any one of the preceding claims, characterized in that the detailed service offerings (42) indicate quality of service information (61 b).
 9. A method according to any one of the preceding claims, characterized in that the detailed service offerings (42) indicate a validity period (46).
 10. A network access element (AAAL) for supporting the access sequence of a mobile node (MN) in one or more foreign domains (FD), characterized by: a service advertisement logic (A1) for sending service advertisement messages (M1) to the mobile node, each service advertisement message comprising: an identifier (41) of the service advertisement message in question; network address/identity information (43) relating to the foreign domain in question; and a detailed service offering (42); and a resource allocation logic (A4) for: receiving a service request message (M2, M3) from the mobile node (MN), the service request message (M2, M3) comprising the mobile node's credentials (54) and an indication (55) of the service offering (62) selected by the mobile node or its user; conveying (M4) the mobile node's credentials (54) to the mobile node's home domain (HD) for authentication and authorization and for receiving an authentication and authorization indication (M7) from the mobile node's home domain (HD); checking if the service indicated by the selected service offering (62) can be supported on the basis of available communication resources; and allocating communication resources if the service indicated by the selected service offering can be supported.
 11. A network access element (AAAL) for supporting the access sequence of a mobile node (MN) in one or more foreign domains (FD), characterized by: a service advertisement logic (Al) for sending service advertisement messages (M1) to the mobile node, each service advertisement message comprising: network address/identity information (43) relating to the foreign domain in question; and a detailed service offering (42); and a resource allocation logic (A4) for: receiving a service request message (M2, M3) from the mobile node (MN), the service request message (M2, M3) comprising the mobile node's credentials (54) and an indication (55) of the service offering (62) selected by the mobile node or its user; conveying (M4) the mobile node's credentials (54) to the mobile node's home domain (HD) for authentication and authorization and for receiving an authentication and authorization indication (M7) from the mobile node's home domain (HD); checking if the service indicated by the selected service offering (62) can be supported on the basis of available communication resources; and allocating communication resources if the service indicated by the selected service offering can be supported.
 12. A network access element (AAAL) for supporting the access sequence of a mobile node (MN) in one or more foreign domains (FD), characterized by: a service advertisement logic (Al) for sending service advertisement messages (M1) to the mobile node, each service advertisement message comprising: an identifier (41) of the service advertisement message in question; network address/identity information (43) relating to the foreign domain in question; and a resource allocation logic (A4) for: receiving a service request message (M2, M3) from the mobile node (MN), the service request message (M2, M3) comprising the mobile node's credentials (54) and an indication (55) of the service offering (62) selected by the mobile node or its user, conveying (M4) the mobile node's credentials (54) to the mobile node's home domain (HD) for authentication and authorization and for receiving an authentication and authorization indication (M7) from the mobile node's home domain (HD); checking if the service indicated by the selected service offering (62) can be supported on the basis of available communication resources; and allocating communication resources if the service indicated by the selected service offering can be supported.
 13. A network access element (AAAL) according to claim 10, 11 or 12, characterized in that the resource allocation logic (A4) is adapted to perform the checking operation after conveying (M4) the mobile node's credentials to the mobile node's home domain.
 14. A network access element (AAAL) according to claim 13, characterized in that the resource allocation logic (A4) is adapted to perform the checking operation before receiving an authentication and authorization indication (M7) from the mobile node's home domain.
 15. A mobile node (MN) capable of performing a network access sequence in one or more foreign domains (FD), characterized by a service advertisement processing logic (A2) for: receiving and storing service advertisement messages (M1) from said one or more foreign domains (FD), each service advertisement message comprising an identifier (41) of the service advertisement message in question; network address/identity information (43) relating to the foreign domain in question; and a detailed service offering (42); forming an indication (55) of a selected detailed service offering (62); and sending a service request message (M2) to the foreign domain (FD) which sent the selected service offering (62), the service request message (M2) comprising the indication (55) of the selected service offering (62) and the mobile node's credentials (54).
 16. A mobile node (MN) capable of performing a network access sequence in one or more foreign domains (FD), characterized by a service advertisement processing logic (A2) for: receiving and storing service advertisement messages (M1) from said one or more foreign domains (FD), each service advertisement message comprising a network address/identity information (43) relating to the foreign domain in question and a detailed service offering (42); forming an identifier (41) of the service advertisement message in question based on the information contained in the service offering (42), and an indication (55) of a selected detailed service offering (62); and sending a service request message (M2) to the foreign domain (FD) which sent the selected service offering (62), the service request message (M2) comprising the indication (55) of the selected service offering (62) and the mobile node's credentials (54).
 17. A mobile node (MN) capable of performing a network access sequence in one or more foreign domains (FD), characterized by a service advertisement processing logic (A2) for: receiving and storing service advertisement messages (M1) from said one or more foreign domains (FD), each service advertisement message comprising an identifier (41) of the service advertisement message in question and network address/identity information (43) relating to the foreign domain in question; extracting a detailed service offering (42) from the identifier (41) and an indication (55) of a selected detailed service offering (62); and sending a service request message (M2) to the foreign domain (FD) which sent the selected service offering (62), the service request message (M2) comprising the indication (55) of the selected service offering (62) and the mobile node's credentials (54).
 18. A mobile node (MN) according to claim 15, 16 or 17, characterized by automatically forming the indication (55) of the selected service offering (62) on the basis of pre-stored criteria.
 19. A mobile node (MN) according to claim 15, 16 or 17, characterized by forming the indication (55) of the selected service offering (62) by presenting the detailed service offerings to a user and by receiving the user's selection. 